--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> I was actually thinking to check GetStopState BEFORE the anomoly, that is after the Stop but before the Jog that causes bad motion.
>  
> Regards
> TK
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Thursday, October 25, 2012 8:05 PM
> Subject: [DynoMotion] Re: First Move After Stop Does ????
>
>  
> Tom,
>
> GetStopState returns 0 after the anomoly. Also, releasing the FeedHold before hitting Stop does not make a difference. *Sometimes* all works as it should, and that's what I seem to have seen earlier.
>
> I do now at least have what seems to be a repeatable test case. I can run a short program, hit FeedHold during a move, then Stop. If I then do an MDI move on the Z axis, both Z and X move. Tomorrow I'll try to aggravate it, and see if I can get a more blatant result, and also try doing the FeedHold and stop through KMotion, using the same sequences of commands my app is using, and see if I can get it to happen outside my app.
>
> BTW - I've got another friend transitioning to KFlop!
>
> Regards,
> Ray L.
>
> --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > Strange.   I can't think of why issuing a halt would have a problem with feedhold.  The first thing it should do is issue a feedhold.
> >  
> > Releasing feedhold before halt will probably work ok 99.9% of the time, but if Windows has a delay for some reason there might be some motion for a second or so.
> >  
> > When you do the failure scenario (Halt while in feedhold), if you do a GetStopState from the KMotion Console what is reported?
> >  
> > Regards
> > TK
> >  
> >
> >
> > ________________________________
> > From: himykabibble <jagboy@>
> > To: mailto:DynoMotion%40yahoogroups.com
> > Sent: Thursday, October 25, 2012 3:59 PM
> > Subject: [DynoMotion] Re: First Move After Stop Does ????
> >
> >  
> > Tom,
> >
> > I discovered today, entirely by accident, that if I do a FeedHold while the machine is in motion, it, of course, stops pretty much where it is. If I then hit Stop, it leaves it in the nasty state where ANY jog or other move will cause a multi-axis rapid move to who knows where. BUT, if I take it out of FeedHold, then immediately hit Stop, it's left in a sane state, and does not do the bogus move. So, that at least gives me one path to avoid the problem.
> >
> > So, it appears to me, what I want to do is:
> >
> > To ENTER FeedHold => StopImmediate0 (I do this now, and it works)
> >
> > To EXIT FeedHold => StopImmediate1 (I do this now, and it works)
> >
> > To Stop, while the program is running => FIRST, IF FeedHold is in effect, do a StopImmediate1 THEN do Interpreter.Halt (I only do the Interpreter.Halt right now, regardless of the FeedHold state, and it appears being in FeedHold when the Halt is executed is what's causing me grief).
> >
> > Other than FeedHold, there is NEVER a time where I expect to be able to stop the interpreter mid-move, and resume from that point. I will either use FeedHold, and release from FeedHold, or, if I do a Stop, whether FeedHold was in effect or not, I am perfectly fine with having to resume on a line boundary, manually setting the initial position for that line, if necessary.
> >
> > Does the logic above seem correct given those conditions? It *seems* to be working, in the limited testing I did today.
> >
> > Regards,
> > Ray L.
> >
> > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > >
> > >
> > > Hi Ray,
> > >  
> > > It is actually StopImmediate0 and StopImmediate1 that will pause and resume execution.
> > >  
> > > I think you will discover that there are many cases where to resume you absolutely must start at other than a line boundary.  For example a simple case is a circle or arc.  If you stopped part way through an arc the I J center coordinates are only valid from the beginning of the original arc.  If you begin executing from the current line (or the next) from where you are the result will be wrong.  There are many more far more complex scenarios.
> > >  
> > > Interpreter.Halt - Is very complex and powerful.  It basically first does an immediate FeedHold, waits until Motion actually Stops, then Clears the Coordinated Motion Buffer, then figures out where the machine tool actually was in the GCode, then re-winds the Interpreter state back to that point from where it may have been working hundreds of lines ahead, then figures out how it would be possible to resume properly within which and where in the number of operations that might have been created by that single line of GCode.  It then calls the Interpreter Callback with enough information that the Application can determine what happened and fixup the back plot.
> > >  
> > > So by default everything is all setup to do a resume as if nothing happened.  To not resume and start anew Interpreter->CoordMotion->m_PreviouslyStopped must be set to 0.  A call to InitializeInterp() should do this.
> > >  
> > > Interpreter.Abort - forces the Interpreter to immediately terminate regardless of what it is doing.  This leaves everything in a totally indeterminate state.
> > >  
> > > StopImmediate2 - Tells KFLOP to exit a feedhold state and discard any unexecuted coordinated motion.
> > >  
> > > Sorry it isn't simple, but it just isn't :}
> > >  
> > > HTH
> > > TK 
> > >  
> > >  
> > >  
> > >  
> > >
> > > ________________________________
> > > From: himykabibble <jagboy@>
> > > To: mailto:DynoMotion%40yahoogroups.com
> > > Sent: Thursday, October 25, 2012 11:45 AM
> > > Subject: [DynoMotion] Re: First Move After Stop Does ????
> > >
> > >  
> > > Tom,
> > >
> > > Not sure I'm completely following you.... Sounds like we agree that using StopImmediate1 and StopImmediate2 will correctly pause and resume execution. And, indeed, my experience is this works perfectly. So, the only problematic condition is I am either already in FeedHold, or not, and hit Stop. At this point, I don't care at all about preserving ANY interpreter state. I'd like it to come to a graceful stop if it's moving, exactly as if I'd hit FeedHold, and then basically clear and reset itself. The ONLY thing I'd like preserved is the current line it was executing, though I'd be OK with even that getting lost, since I can restore it by re-starting the Interpreter and telling it to start there. There is no case where I'd expect it to resume execution, other than at a line boundary. So, sounds like I should do a StopImmediate2, instead of Interpreter->Halt? Can I then just do a Interpreter->Interpret, passing the same file, and the last compleleted
> line
> > > number as the start line, to cause it to safely forget about what it was doing, and get ready to re-start the program from the specified line (leaving the user to make sure the machine is in a reasonable state to do that)?
> > >
> > > I'm really not at all clear as to *exactly* what Interpreter.Halt, Interpreter.Abort, and StopImmediate2 actually do....
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > > ÃÆ'‚ 
> > > > Regarding StopImmediate2:ÃÆ'‚ When running a coordinated motion path 0 and 1 allow feedhold and resume.ÃÆ'‚  When in feedhold KFLOP is still internally executing the path (ready to resume at any instant) and the coordinated motion buffer mechanism is still busy and in use.ÃÆ'‚  In the event that you are in feedhold and wish to totally discard the remainder of the coordinated motion path and put the coordinated motion mechanism in an idle state issue a StopImmediate2.
> > > >
> > > > Your problem might be regarding:
> > > >
> > > > ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  Interpreter->CoordMotion->m_PreviouslyStopped=0;
> > > >
> > > > There is a complex mechanism to resume after a halt part way through a previously executed line of GCode.ÃÆ'‚  Imagine the system is part way through a radius compensated arc and halted, then the system is Jogged, tool replaced, and then we wish to resume.ÃÆ'‚  It is up to your Application to clear the previously stopped condition if you do not want to resume where you left off.ÃÆ'‚  I see KMotionCNC clears that state directly in various cases.ÃÆ'‚  But it doesn't look like that is exposed to the .NET interface.ÃÆ'‚  I see
> > > >
> > > > int CGCodeInterpreter::InitializeInterp(void)
> > > >
> > > >
> > > > Clears it.ÃÆ'‚  Which is exposed as:
> > > >
> > > > extern "C" __declspec(dllexport) ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  bool __stdcall KM_dotnet_Interop_GCodeInterpreter_InitializeInterpreter(int *handle)
> > > >
> > > >
> > > > and in C# as:
> > > >
> > > > ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  /// <summary>
> > > > ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  /// Resets the interpreter params to the inital state
> > > > ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  /// </summary>
> > > > ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚ ÃÆ'‚  public void InitializeInterpreter()
> > > >
> > > >
> > > > Are you calling that?
> > > >
> > > > Regards
> > > > TK
> > > >
> > > > ÃÆ'‚ 
> > > > ÃÆ'‚ 
> > > >
> > > > From: himykabibble <jagboy@>
> > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > Sent: Thursday, October 25, 2012 7:58 AM
> > > > Subject: [DynoMotion] Re: First Move After Stop Does ????
> > > >
> > > > ÃÆ'‚ 
> > > > Tom,
> > > >
> > > > My FeedHold is a toggle that pauses and resumes program execution. FeedHold, by itself, works perfectly. So, perhaps it is the FeedHold->Stop sequence that is causing my problem. I am not at all clear on the difference between StopImmediate1 and StopImmediate2. When would I use StopImmediate2?
> > > >
> > > > For Stop, I simply want to abort Interpreter operation entirely. This can be very brute force, if necessary, other than gracefully stopping motion. I am currently using Interpreter.Halt for this. And, yes, Interpreter.Halt is absolutely being called. The problem is, once it's been called, there seems to be a disconnect between where the machine is, and where the interpreter wants it to be, such that ANY attempt to move the machine will cause a multi-axis rapid move to a new position (I have no idea where this new position comes from - it does not appear to be anything logical to me). If the tool is buried
> > > > in the work when the Stop occurs, this means the tool WILL get broken.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In mailto:DynoMotion%40yahoogroups.com, TK <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > >
> > > > > You will probably need to debug your code. It will be difficult to figure out what is going on by just looking at a couple of code fragments. Especially without knowing the details of what you are doing and what happens. Halting and resuming GCode sounds easy but it is incredibly complex. When you can single step through a known failure sequence it is far easier to understand what is going wrong rather than trying to deduce it.
> > > > >
> > > > > But here are some thoughts:
> > > > >
> > > > > The StopImmediate (freehold) command can do 3 things: basically freehold, resume, clear. I don't see how you are ever clearing coordinated
> > > > motion.
> > > > >
> > > > > http://dynomotion.com/Help/Cmd.htm#StopImmediate
> > > > >
> > > > > Although Interpreter.Halt is designed to handle it all for you: Feedhold, wait, clear, save resume position/mode, backup Interpreter state, and abort Interpreter.
> > > > >
> > > > > However the Interpreter is running as a separate thread. So the Halt is only a request for all that to happen. It will take some time for the Interpreter to honor the request and do all those tasks and notify you with the Complete callback what happened.
> > > > >
> > > > > It seems that you have conditions around even calling the Interpreter.Halt. Do you know it is really being called? Are you verifying the Complete Callback is really happening to indicate the Interpreter Thread is really finished?
> > > > >
> > > > > But on the other hand (as I said in an earlier email) it seems more like the problem
> > > > is on starting the interpreter than stopping it. After stopping you should be able to change any number of things (axis positions) and the interpreter should sync to all the current positions before starting.
> > > > >
> > > > > TK
> > > > >
> > > > > On Oct 24, 2012, at 6:27 PM, "himykabibble" <jagboy@> wrote:
> > > > >
> > > > > > Tom,
> > > > > >
> > > > > > I REALLY need to get to the bottom of this problem. It's cost me several tools over the last week. Below is my code for handling FeedHold and Stop. I don't see anything that should cause a problem, yet these multi-axis moves happen quite consistently following a stop. I've actually taken to disabling the servos, and *manually* cranking the quill up until the tool is clear of the work before trying to do a move after a Stop.
> > > > > >
> > > > > > As you can see,
> > > > > >
> > > > > > private void DoFeedHold()
> > > > > > {
> > > > > > try
> > > > > > {
> > > > > >
> > > > KM.SetFeedHold();
> > > > > > if (KM.IsInFeedHold())
> > > > > > GCodeState |= GCodeStates.InFeedHold;
> > > > > > else
> > > > > > GCodeState &= ~GCodeStates.InFeedHold;
> > > > > > }
> > > > > > catch
> > > > > > {
> > > > > > MessageBox.Show("Caught Exception in FeedHoldButtonClick");
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > private void DoStop()
> > > > > > {
> > > > > > if ( ( GCodeState & GCodeStates.RunningMask ) != 0 ) {
> > > > > > if ( RunningGCodeFile.IsOpen )
> > > > > > GCodeState = GCodeStates.GCodeLoaded;
> > > > > > else
> > > > > > GCodeState = GCodeStates.Idle;
> > > > > > KM.InterpreterStop();
> > > > > > } else
> > > > > > KM.DoJogStop();
> > > > > > if (KM.SpindleIsOn())
> > > > > > {
> > > > > > KM.SetSpindle(SpindleStates.Off, 0);
> > > > > > ((LEDButton)CWButton).SetActive(false);
> > > > > > ((LEDButton)CCWButton).SetActive(false);
> > > > > > }
> > > > > > if
> > > > (KM.CoolantIsOn())
> > > > > > {
> > > > > > KM.SetMistCoolant(false);
> > > > > > ((LEDButton)MistButton).SetActive(false);
> > > > > > KM.SetFloodCoolant(false);
> > > > > > ((LEDButton)FloodButton).SetActive(false);
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > public void InterpreterStop()
> > > > > > {
> > > > > > KMController.CoordMotion.Interpreter.Halt();
> > > > > > FeedHoldIsOn = false;
> > > > > > }
> > > > > >
> > > > > > public void DoJogStop()
> > > > > > {
> > > > > > if (KMConnected())
> > > > > > {
> > > > > > KMController.WriteLine( "Jog 0 = 0" );
> > > > > > KMController.WriteLine( "Jog 1 = 0" );
> > > > > > KMController.WriteLine( "Jog 2 = 0" );
> > > > > > KMController.WriteLine( "Jog 3 = 0" );
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > public void SetFeedHold()
> > > > > > {
> > > > > > try
> > > > > > {
> > > > > > String s = KMController.WriteLineReadLine("GetStopState");
> > > > >
> > > > > if (s.Equals("0"))
> > > > > > {
> > > > > > KMController.WriteLine("StopImmediate0");
> > > > > > FeedHoldIsOn = true;
> > > > > > }
> > > > > > else
> > > > > > {
> > > > > > KMController.WriteLine("StopImmediate1");
> > > > > > FeedHoldIsOn = false;
> > > > > > }
> > > > > > }
> > > > > > catch (Exception e) { DoDisconnect(e); }
> > > > > > }
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In mailto:DynoMotion%40yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > > > > > >
> > > > > > > Tom,
> > > > > > >
> > > > > > > I really don't remember.... I'll have to take a look at the code. I believe it call the interpreter, passing the file patch and the current line number.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > > >
> > > > > > > > Hi Ray,
> > > > > > > >
> > > > > > > > That seems strange. In KMotionCNC SetNextLine to the current line wouldn't do or change anything. What does it do in your Application? Also it doesn't really make sense to sync the interpreter at a Stop. It needs to be done at the time of the next start of the interpreter because things may have changed in the mean time.
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > TK
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ________________________________
> > > > > > > > From: himykabibble <jagboy@>
> > > > > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > > > > Sent: Monday, October 15, 2012 9:59 AM
> > > > > > > > Subject: [DynoMotion] Re: First Move After Stop Does ????
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Tom,
> > > > > > > >
> > > > > > > > This never happens on a FeedHold, so I have to assume my FeedHold handler is OK. I'll look at what I do on a Stop. I believe I just do an Abort. Perhaps what I should do is Abort, then re-start the Interpreter at the current line. I have found that if I do a Stop, SetNextLine (to the current line), then jog or Run, this does not happen, which suggests the Interpreter state is getting whacked somehow, no?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ray L.
> > > > > > > >
> > > > >
> > > > > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > > > >
> > > > > > > > > Hi Ray,
> > > > > > > > >
> > > > > > > > > I don't think KMotionCNC has this behavior so I suspect it is something in how your Application handles Stop.
> > > > > > > > >
> > > > > > > > > On a starting GCode (or an MDI) after a Stop (or in all cases really) the Interpreter is synced to the current locations before execution.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ If somehow this wasn't happening I could see how some of the axes would move back to their previously known positions within the Interpreter.ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡ But the sync is built into the Interpreter so it isn't clear how this could not be happening.
> > > > > > > > >
> > > > > > > > > I believe a Jog happens within
> > > > your code within KFLOP of one axis so I can't think of how that might cause the other axes to move, unless somehow it is still in feedhold and it resumes.
> > > > > > > > >
> > > > > > > > > Can you come up with a more exact and specific scenario that shows the problem repeatedly?
> > > > > > > > >
> > > > > > > > > Regards
> > > > > > > > > TK
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ________________________________
> > > > > > > > > From: himykabibble <jagboy@>
> > > > > > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > > > > > Sent: Sunday, October 14, 2012 4:01 PM
> > > > > > > > > Subject: [DynoMotion] First Move After Stop Does
> > > > ????
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ÃÆ'Æ'Æ'ÃÆ'¢â‚¬Å¡
> > > > > > > > > Tom,
> > > > > > > > >
> > > > > > > > > Here's something that has bitten me several times: If I'm running a program, and want to interrupt it, I will usually do a FeedHold, then a Stop. But, after doing this, the next move, if I try to jog the machine, or do an MDI move, it will often move multiple axes, resulting in a crash. Typically, all I want to do it jog the Z axis up, to clear the part, but as soon as I try to do that, it does a 2- or 3-axis move, crashing, and usually breaking, the tool. Why? How do I prevent this?
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Ray L.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>